As for the API, we follow WebGPU, only deviating when necessary.

Looks like push constants are part of the ProgrammableStage dict that's embedded in the args passed to create_render_pipeline()

From https://gpuweb.github.io/gpuweb/#gpuprogrammablestage:

That constants must be a dict mapping constant name to constant value (A GPUPipelineConstantValue is really just a double).

@almarklein :

That's a different feature, but with a similar name. It lets you create variables that are "almost constant" but can be changed at pipeline creation time. It's actually part of the webgpu spec, but not implemented in the current wgpu.

https://gpuweb.github.io/gpuweb/wgsl/#override-decls

The API for createPipelineLayout was inspired by Rust's PipelineLayoutDescriptor which has two public fields, bind_group_layouts and push_constant_ranges. I let the fields of the dictionary match the fields of the wgpu.h API, except that stages become visibility in line with other locations.

The API for set_push_constants is precisely equivalent to that in wgpu.h. I think there needs to be an optional data_offset field added to make this code similar to write_buffer.

I'm a little bit bothered that limits are snake_case_with_underscores while features are snake-case-with-hyphen. This makes the code for adapter.get_device() look a little bit strange. I went ahead and fixed this. Let me know if I shouldn't have done this.

That's a different feature, but with a similar name.

Ah, both of these are new to me, so I mixed them up.

If I understand correctly, push constants are a feature specific to wgpu-native, not present in WebGPU. In that case, the API should not be in _classes.py, because that api should be mappable to any WebGPU(ish) backend. So far, we've implemented wgpu-native-specific features in backends/wgpu_native/extras.py, which get exposed in the wgpu.backends.wgpu_native namespace. That way it is clear when code uses 'special' functionality and might therefore be less portable.

Code should now accept my_feature, my-feature, and myFeature for limit and feature names.
Still need to work on doc.rst, but everything else should be done.
_classes.py should be unchanged by this CL, since all changes are wgpu-native specific.

Don't review yet. Premature. _api.py is going to be a painful merge. Working on it.

Merge is complete and is ready to be reviewed (but not quite ready for submission).

When I run pytest tests_mem on my Mac, everything works fine. But the test fails as part of the test suite on Linux with

----------------------------- Captured stdout call ----------------------------- more after create: {'RenderBundle': (32, 32), 'RenderBundleEncoder': (32, 0)} =========================== short test summary info ============================ FAILED tests_mem/test_objects.py::test_release_render_bundle - AssertionError: Expected: {'RenderBundle': (32, 32)} Got: {'RenderBundle': (32, 32), 'RenderBundleEncoder': (32, 0)} =================== 1 failed, 28 passed, 2 skipped in 8.11s ====================

I've no idea why I'm getting different results on the two. I also confess I don't understand what @test_and_release is testing and what the two numbers are supposed to represent. The decorator has no documentation saying what its arguments mean.

This is ready for review.
I'm not completely happy with test_objects(), but both both branches "main" and this branch both fail on my Mac. Apparently there is a slight difference in the implementation of render bundles.

@almarklein: I do wish it were better documented what @create_and_release was testing, and what the two numbers are. Python objects and native objects?

@almarklein: I do wish it were better documented what @create_and_release was testing, and what the two numbers are. Python objects and native objects?

Sorry for the missing docs here. Yeah, they are Python and native (Rust) objects. Would you mind adding that to the docstring in this pr?

I'm not completely happy with test_objects(), but both both branches "main" and this branch both fail on my Mac. Apparently there is a slight difference in the implementation of render bundles.

Is that resolved? I don't see a change in test_objects() now.

Thanks!